Network mobility

ABSTRACT

In a wireless network environment comprising a mobile router serving a moving network, said mobile router for attaching to a packet-switched access network that uses a micro-mobility protocol and a Quality of Service (QoS) protocol to route packet data to and from said mobile router, wherein said mobile router has a QoS aggregate requirement generated by nodes attached thereto, a method of handover of said mobile router to a mobility agent in said access network, which method comprises the steps of: (i) said mobile router sends a QoS request message to said mobility agent, which QoS request message comprises a QoS parameter representing said QoS aggregate; (ii) upon receipt by said mobility agent, said access network takes a QoS admission decision on the basis of said QoS parameter; and (iii) said mobility agent sends a QoS acknowledgement to said mobile router whereby said mobility agent informs said mobile router of the outcome of said QoS admission decision; characterized by the step of (iv) if said QoS admission decision is that said mobility agent cannot handle all of said QoS aggregate, said QoS acknowledgement comprises an identity of one or more alternative mobility agent that might meet at least a part of said QoS aggregate that will not be provided by said mobility agent.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 12/634,394 filed on Dec. 9, 2009 which claims foreign priorityto United Kingdom Patent Application Serial Number 08 228 15.7 filedDec. 15, 2008, the entire disclosure of which is herein incorporated byreference. The benefit of such earlier filing dates is hereby claimed byapplicant under 35 U.S.C. §120.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method of handover of a mobile routerto a mobility agent, to a packet-switched access network for taking partin the method, to a router for use in the method, to a mobile router foruse in the method, and to a vehicle comprising such a mobile router.

2. Description of the Related Art

Many different requirements are expected of the network layer in all-IPaccess networks (e.g. 4G cellular networks). Two in particular aremobility and QoS. The former enables users to communicate seamlesslywith remote network nodes via the Internet wherever they are, whereasthe latter enables users to receive different levels of service forcertain types of traffic.

Mobility at the network layer is concerned with maintaining theroutability of packet data to and from a mobile node when that mobilenode moves away from its home access network. The main candidate forprovision of this functionality is Mobile IP (MIP). Very briefly MIPrelies on a Home Agent in the home access network to tunnel IP packetsto the domain where the mobile node is attached. The mobile node forms aCare-of Address (CoA) that is globally topologically correct in thenetwork to which it is attached. The Home Agent encapsulates packetsthat it receives addressed to the mobile node's home address in anotherIP packet addressed to the CoA. In this way packet data may still reachthe mobile node even when it is away from the home network. Furtherdetails of Mobile IP can be found in RFC 3344, 3775 and 3776 to whichreference is specifically made.

However, when a mobile node hands over to a new access router, bindingupdates are triggered to the Home Agent, etc. These binding updates canintroduce unwanted delays and loss of packets, and thereby degradationin performance from the user's perspective. When attached to aparticular wireless access network (such as a cellular network), amobile node may change its point of attachment (i.e. access router)quite frequently (e.g. every few minutes or more often, particularly ifon the move). Each change triggers configuration of a new CoA, followedby the necessary binding updates. Doing this frequently (e.g. every fewminutes) is not practical.

Hierarchical Mobile IPv6 (HMIPv6) has been proposed (see RFC 4140) toaddress this problem. HMIPv6 provides a mobility agent known as aMobility Anchor Point (MAP) in the access network. A MAP is a logicalentity that handles micro-mobility for the mobile node. Micro-mobilityis a change in point of attachment of the mobile node from one accessrouter to another, both of which are within the same domain of theaccess network. Whenever this happens, the mobile node sends a bindingupdate to the MAP (comprising a new Link local CoA or LCoA), but themobile node's primary CoA (or Regional CoA or RCoA) remains unchanged.In this way the mobile node can move between access routers in the sameadministrative domain without having to send a binding update to theHome Agent. In contrast when the mobile node changes point of attachmentto an access router in a different access network, this is amacro-mobility event i.e. requiring a binding update to be sent to theHome Agent of the mobile node.

It is possible that the mobile node may take the form of a movingnetwork, a specific example of which is called a ‘network in motion’ orNEMO network. Network mobility support is concerned with managing themobility of an entire network, viewed as a single unit, which changesits point of attachment to a fixed network infrastructure and thus itsreachability in the network topology, most frequently the Internet. Themobile part of the network is referred to as a ‘moving network’, thatcan be installed in a train for example, and which includes one or more‘mobile routers’ (MRs) which act as gateways to the moving network andconnect it to the global Internet. Nodes behind the MR(s) can beclassified as “Local Fixed Nodes” (LPNs) such as wired Internet accesspoint on the train, Local Mobile Nodes (LMNs) such as mobile PDAscarried by personnel working on the train, and Visiting Mobile Nodes(VMNs) such as notebook computers, PDAs, portable media players,hand-held gaming devices and mobile telephones carried by passengers onthe train. In most cases, the internal structure of the moving networkwill in effect be relatively stable (no dynamic change of the topology),subject to joining and leaving of VMNs and LMNs. The MR provideswireless access for the network nodes via access routers that are partof the fixed network infrastructure. Access routers include satellites,UMTS Node Bs, GSM base stations, DVB transmitters and wireless accesspoints.

The mobility of moving networks does not cause the network nodes tochange their own physical point of attachment, although they happen tochange their topological location with respect to the global Internet.If network mobility is not explicitly supported by some mechanism, themobility of the MR results in mobile nodes losing Internet access andbreaking ongoing connections with correspondent nodes (hereinafter CNs)in the global Internet. In addition, the communication path between thenetwork nodes and the CNs becomes sub-optimal, and nested mobility willcause yet worse routing paths.

The current solution to provide network mobility is promoted by theNEtworks in MOtion (NEMO) working group of the Internet Engineering TaskForce (see www.ietf.org/html.charters/nemo-charter.html). “NEMO BasicSupport” (see RFC 3963 at the same website) aims to provide connectioncontinuity for nodes in the moving network.

NEMO Basic Support provides connection (or session) continuity (e.g.continuity for TCP connections) by creating a “bi-directional tunnel”between the MR and its home network. This bi-directional tunnel isformed by encapsulating IP packets to and from the network nodes in IPpackets addressed between the MR and a Home Agent on the MR's homenetwork. In this way traffic flows are routed via the MR and its HomeAgent and the mobility of the moving network is transparent to allnetwork nodes attached thereto.

We have realized that mobile routers that arrive within the signalcoverage of an access network that operates both a micro-mobilityprotocol, such as HMIPv6, and a QoS protocol, face particulardifficulties. In particular, when an access network operates both amobility protocol (such as HMIPv6) and a QoS protocol (such as DiffServor IntServ), the requirement that all packets to and from the movingnetwork pass through a single mobility agent creates a bottleneck whichwill lead to congestion in the router hosting the mobility agent and atother routers nearby.

Furthermore, the utilization of the mobility agent's resources is alwayslikely to be relatively high since all traffic within its domain mustpass through it. This bottleneck can be particularly problematic formoving networks utilizing aggregated QoS reservations, in which a highnumber of mobile terminals (e.g. ten, twenty, one hundred or more) mayrequire the simultaneous and substantially seamless handover of ongoingsessions to a single mobility agent. We have realized that the mainproblem is the possibility that no single mobility agent within the newnetwork is likely to have the capacity to support the resourcerequirements of the moving network as a whole. If so, the mobility agentwill reject the resource request of the moving network, causing themobile router either to blindly seek alternative mobility agents withwhich to make a resource reservation, or negotiate a lower resourcereservation with the mobility agent, with the intention of eitherdropping the sessions of some mobile nodes, or proportionally reducingthe QoS given to all sessions.

In both of these situations, handover latency will be significantlyincreased as the mobile router attempts to establish a reservation witha mobility agent that can accommodate the resource requirements of themoving network, assuming that there is another mobility agent availablein that access network.

SUMMARY OF THE INVENTION

According to the present invention there is provided in a wirelessnetwork environment comprising a mobile router serving a moving network,said mobile router for attaching to a packet-switched access networkthat uses a micro-mobility protocol and a Quality of Service (QoS)protocol to route packet data to and from said mobile router, whereinsaid mobile router has a QoS aggregate requirement generated by nodesattached thereto, a method of handover of said mobile router to amobility agent in said access network, which method comprises the stepsof:

(i) said mobile router sends a QoS request message to said mobilityagent, which QoS request message comprises a QoS parameter representingsaid QoS aggregate;

(ii) upon receipt by said mobility agent, said access network takes aQoS admission decision on the basis of said QoS parameter; and

(iii) said mobility agent sends a QoS acknowledgement to said mobilerouter whereby said mobility agent informs said mobile router of theoutcome of said QoS admission decision; characterized by the step of

(iv) if said QoS admission decision is that said mobility agent cannothandle all of said QoS aggregate, said QoS acknowledgement comprises anidentity of one or more alternative mobility agent that might meet atleast a part of said QoS aggregate that will not be provided by saidmobility agent. In some embodiments of the invention, providing theidentity of one or more alternative mobility agent to the mobile routerprovides the possibility that the mobile router will not have todowngrade its QoS request and/or drop certain sessions. In particular,by registering with alternative mobility agents the mobile router may beable to distribute its traffic across several different mobility agents.It will be understood that the term moving network does mean that thenetwork is always in motion, but rather is intended to reflect itscapability to move or be in motion from time to time.

In some embodiments, the mobile router comprises a single interface forcommunication with the ‘fixed’ part of the access networkinfrastructure, and all of the traffic of the mobile router is sent to asingle access router at any one particular time.

The micro-mobility protocol may be a tunnelling type such as HMIPv6, orany similar protocol similar, or any protocol derived from HMIPv6. TheQuality of Service (QoS) protocol may be IntServ or DiffServ, or anysimilar protocol similar, or any protocol derived therefrom.Accordingly, the QoS admission decision may be taken by a single logicalentity, such as a bandwidth broker, for the whole network (e.g. whenoperating DiffServ); alternatively the QoS admission decision may betaken by each mobility agent that receives a QoS request based onknowledge the link state of paths in the network. Such link-stateknowledge may be gained from an intra-domain link-state routingalgorithm such as QoSPF for example.

In certain embodiments said QoS request comprises a Binding Updatemessage in which said QoS parameter representing said QoS aggregate issent within a Mobility Options part of said Binding Update message,whereby upon receipt of said Binding Update said mobility agent isinformed both about a care-of address that said mobile router intends touse and a desired QoS. The Binding Update may be a local Binding Updatein accordance with that specified in RFC 4140. By using a Binding Updatemessage to send the QoS parameter(s) the mobility agent is informed atthe same time about mobility and about the QoS requirements of themoving network. In other embodiments the QoS request message maycomprise a login type message that comprises said QoS parameter.

In some embodiments, said QoS admission decision comprises determining aproportion of said QoS aggregate that said mobility agent can provide,and sending data representing said proportion in said QoSacknowledgement to said mobile router. The proportion can be given interms of one or more permitted or rejected traffic class (e.g. a UMTStraffic class), and/or in terms of a certain permitted bandwidth.

In certain embodiments said QoS acknowledgement comprises a BindingAcknowledgement type message and said identity of said one or morealternative mobility agent is sent within a Mobility options part ofsaid Binding Update. The Binding Acknowledgement may be a local BindingAcknowledgement as described in RFC 4140. By using a BindingAcknowledgement, the mobile router is informed at the same time bothabout mobility (i.e. whether or not it registration request has beensuccessful) and about QoS (i.e. whether or not the mobility agent canhandle at least some of its QoS aggregate). This helps to reduce thetime taken for completion of handover.

In some embodiments said QoS acknowledgement further) comprises anindication of resources available at said one or more other mobilityagent. For example, the QoS Acknowledgement may indicate how muchbandwidth (e.g. in MB s is available, and/or which traffic classes areacceptable at each alternative mobility agent.

In certain embodiments data representing QoS that will be provided bysaid mobility agent for said mobile router is sent in a Mobility Optionspart of said Binding Acknowledgement, whereby upon receipt of saidBinding Acknowledgement said mobile router is informed both about acare-of address that has been registered by said mobility agent for saidmobile router and about the QoS that said mobility agent is ableprovide.

In some embodiments upon receipt of said QoS acknowledgement said mobilerouter sends a further QoS request to one of said one or morealternative mobility agent, which further QoS request seeks reservationof the remainder of said QoS aggregate that has not been admitted bysaid access network through said mobility agent. In this way the mobilerouter may establish more than one route for its traffic across theaccess network, reducing the likelihood that its QoS aggregate must bedowngraded.

In certain embodiments the method further comprises the steps of saidmobile router sending QoS requests to different mobility agents, untilsaid QoS aggregate is supported by said access network via a number ofdifferent mobility agents, until no untried mobility agents are left insaid access network, or until a predetermined number of QoS requestshave been sent by said mobile router.

After having made one or more registration with one or more mobilityagent, the mobile router advises its home agent, known as a mobilerouter home agent, thereby establishing several tunnels through whichdata may flow to and from the moving network.

In some embodiments, the method further comprises the steps of saidmobile router registering with at least two mobility agents, and sendingat least one Binding Update to a mobile router home agent whereby eachcare-of address (RCoA) of said mobile router at each mobility agent isstored in a binding cache of said mobile router home agent, so thattraffic passing between said mobile router home agent and said mobilerouter is split between at least two tunnels, each tunnel passingthrough a different mobility agent, whereby said access network is ableto support a greater proportion of said QoS aggregate than wouldotherwise be supported by a single mobility agent. The Binding Updatemay be of the type specified in the NEMO Basic Support Protocol.

In certain embodiments said Binding Update comprises a list of the oreach care-of address belonging to the mobile router, the method furthercomprising the step of upon receipt of said Binding Update said mobilerouter home agent amending its binding cache to match said list. In thisway the mobile router keeps the mobile router home agent informed aboutall of its current bindings with each binding update.

In some embodiments said Binding Update further comprises a QoSparameter which is mapped to a respective care-of address in said list,the method further comprising the step of said mobile router home agentsplitting downstream traffic between said care-of addresses according tosaid QoS parameters. In this way the mobile router informs the mobilerouter home agent what QoS it has agreed with each mobility agent, andthe mobile router home agent splits traffic through each tunnelaccordingly. If the mobile router is in handover from one mobility agentto another (either in the same or different access networks), thepresence of two tunnels, one through the old mobility agent and anotherthrough the new, helps to reduce packet loss and delays during thehandover.

In certain embodiments, the method further comprises the steps ofsending relatively delay intolerant traffic through one of said at leasttwo tunnels, and sending relatively delay tolerant traffic throughanother of said at least two tunnels.

In certain embodiments, the method further comprises the step of sendingone or more class of traffic through one of said at least two tunnels,and sending at least one other class of traffic through another of saidat least two tunnels.

In certain embodiments, (i) follows completion of a mobility part ofsaid handover. The mobility part of the handover may comprise the stepsof the mobile router sending a local binding update, said mobility agentregistering the care-of address of said mobile router, and sending aBinding Acknowledgement to the mobile router to confirm that the newcare-of address under said micro-mobility protocol is registered. Thusthe invention is able to operate independently of mobility if desired.

In some embodiments said QoS request comprises a combined mobility andQoS request, whereby upon receipt of said combined request said mobilityagent registers said mobile router in a binding cache for the purposesof mobility, and said access network takes said QoS admission decisionfor said QoS aggregate of said mobile router, before sending a combinedmobility and QoS acknowledgement to said mobile router. In this way,both mobility and QoS can be handled together by the network, therebyreducing delays caused by performing each part sequentially. Thecombined mobility and QoS request may take the form of a local BindingUpdate as mentioned above, in which the Mobility options part of themessage is used to send QoS information. Thus the invention alsoprovides a way for mobility and QoS procedures to be combined, whichspeeds up the handover process and reduces chances of packet loss andsession interruption.

In accordance with another aspect of the present invention there isprovided a packet-switched wireless access network configured to performthe packet-switched access network method steps set out above.

In accordance with another aspect of the present invention there isprovided a router comprising a memory storing computer executableinstructions that when executed perform the mobility agent method stepsset out above.

In accordance with yet another aspect of the present invention there isprovided a mobile router comprising a memory storing computer executableinstructions that when executed perform the mobile router method stepsset out above.

In accordance with another aspect of the present invention there isprovided a vehicle comprising a mobile router as set out above.

In accordance with another aspect of the present invention there isprovided in a wireless network environment comprising a mobile routerserving a moving network, said mobile router for attaching to apacket-switched access network that uses a micro-mobility protocol and aQuality of Service (QoS) protocol to route packet data to and from saidmobile router, wherein said mobile router has a QoS aggregaterequirement generated by nodes attached thereto, a method of handover ofsaid mobile router to a mobility agent in said access network, whichmethod comprises the steps of said mobile router sending a combinedmobility and QoS request to said mobility agent, whereby upon receipt ofsaid request said mobility agent registers said mobile router in abinding cache for the purposes of mobility, and said access networkmakes a QoS admission decision for said QoS aggregate of said mobilerouter, before sending a combined mobility and QoS acknowledgement tosaid mobile router.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of how the invention may be put intopractice, preferred embodiments of the invention applied in aheterogeneous network environment comprising two access networks will bedescribed, by way of example only, with reference to the accompanyingdrawings, in which:

FIG. 1 is a schematic block diagram of a network environment comprisingtwo access networks, one of which does not operate a tunnelling-typemicro-mobility protocol and the other which does operate such aprotocol;

FIG. 2A is a schematic block diagram of computer hardware for storingand operating logical entities according to the present invention;

FIG. 2B is a schematic block diagram of a mobile node according to thepresent invention;

FIG. 3 is a signalling diagram of an inter-access network handover of amoving network to an access network according to the present invention;

FIG. 4 is a block diagram of part of the network environment of FIG. 1illustrating an intra-access network handover of the a moving network;and

FIG. 5 is a signalling diagram of the intra-access network handovershown in FIG. 5.

DETAILED DESCRIPTION OF THE INVENTION

Referring to FIG. 1 an IP-based (IPv4 or IPv6 or a mixture thereof maybe used in any of the networks mentioned herein) network environmentgenerally identified by reference numeral 10 comprises an IP backbone 12having a number of interconnected routers that provide access fornetwork nodes to data and services stored on remote servers for example.As such the IP backbone 12 may form part of the Internet. In thisembodiment any of two IP-based access networks 14 and 16 provide accessfor a moving network 18 (also known as a network in motion or a NEMOnetwork) to the IP backbone 12, although there may be any number ofaccess networks and moving networks of course. The name ‘moving network’should be taken to imply that the network is permanently in motion;rather the term reflects the ability of a network to be in motion fromtime to time, such as networks provided in vehicles or other modes oftransport. The access networks 14 and 16 may be an IP-based cellularnetwork (such as 3GPP Release 5 or 6, UMTS Long Term Evolution (LTE) orany future IP-enabled cellular network) or the combination of an ISP anda number of WLAN routers for example.

The moving network 18 comprises a mobile router (MR) 20, serving aVisiting Mobile Node (VMN) 22 (that is multi-mode) via an access point(AP) not shown. The AP may be a wireless access point or a wired accesspoint. The moving network 18 is part of a train (or other vehicle suchas a bus, coach or boat) that moves relative to the two access networks14 and 16. As such, the moving network 18 is physically separate fromthe access networks 14 and 16 but may communicate with one or more ofthem by means of a wireless link. The MR 20 has an ingress interface forreceiving IP packets from and transmitting IP packets to network nodesin the moving network 18, and an egress interface for receiving IPpackets from and transmitting IP packets to the fixed packet-switchednetwork i.e. access network 14 or 16. As explained above, one of theaims of the NEMO Basic Support is to ensure that the motion of themoving network 18 is transparent to any network nodes (LPN, LMN and/orVMN) behind the MR 20. Motion of the train past access routersnecessitates network layer handover of service from one access router toanother. Since the MR 20 connects an entire network to remote packetnetworks, each change in point of attachment (i.e. change in accessrouter) to the remote packet networks causes the reachability of theentire moving network 18 to change. Without appropriate mechanisms,connections established between nodes in the moving network 18 and nodesin the remote packet networks cannot be maintained across each handover.Connection continuity is primarily achieved in NEMO Basic Supportthrough establishment of a bidirectional tunnel (herein NEMOBT) betweenthe MR 20 and a Home Agent (MRHA) 26 of the MR 12. Aspects of theoperation of the NEMOBT relevant to the present invention will bebriefly described below. Further details can be found in RFC 3963.

Access to the IP backbone 12 enables LPNs, LMNs and VMNs 22 within themoving network 18 to communicate with one or more remote correspondentnode (CN) 24. As shown the CN 24 may be a media server, a web server oranother mobile node or moving network for example.

Each access network 14 and 16 defines an administrative domaincomprising a number of interconnected routers; therefore the domain isscoped so that at the edges of the network administration packets (suchas link-state advertisements are dropped). Furthermore each accessnetwork 14 and 16, and the mobile router 20, and the LPN, LMN and VMNsare able to operate Mobile lPv6 (MIPv6—see RFC 3775) and HierarchicalMobile lPv6 (HMIPv6) as described in RFC 4140, or any functionallysimilar protocols. Both of these RFCs are fully incorporated herein byreference for all purposes. Thus each access network 14 and 16 comprisesone or more router having the functionality of a mobility agent (orMobility Anchor Point (MAP) in the terms of RFC 4140). The MAP is usedby the moving network 18 as a local Home Agent so that handovers betweenaccess routers in the same domain do not trigger a binding update to theMRHA 26 of the mobile router 20. The domain of each MAP is defined bythe access routers that advertise the MAP Option. As such there may bemore than one MAP per access network. [0048] Each access network 14 and16 is substantially similar in terms of hardware components andtherefore only access network 16 will be described in detail. Accessnetwork 16 comprises a number of interconnected IP packet routers 24. Agateway router (GW) 28 is the only entry and exit point of the accessnetwork 14 for packet traffic to and from the IP backbone 12. Eachrouter 24 is IntServ-capable (see e.g. RFC 1633) and resources may bereserved using a reservation protocol such as RSVP (see RFC 2205). Assuch each router 24 comprises: a packet scheduler for managing theforwarding of different packet streams that arrive; a classifier formapping incoming packets to the right traffic class; and an admissioncontrol component for implementing a decision algorithm to determinewhether a new flow can be granted the requested QoS without impactingearlier guarantees.

A number of IP-enabled access routers (ARs) 30 are located at the edgeof the access network 16. Each access router 30 is a single hop (at thenetwork layer) from the moving network 18, and each is connected to awireless transceiver such as Node B or WLAN router for example.

As mentioned above, the access network comprises one or more MAP ormobility agent. In this embodiment three mobility agents hereinafterreferred to as Enhanced Nodes (EN) 32, 34 and 36 have the basicfunctionality of one of the routers 24 and the functionality provided bya MAP as described in RFC 4140, but additionally comprises functionalityas described herein. In particular, the primary functionality of an ENis to gather QoS, security and mobility information from various partsof the access network and to share this information with other logicalentities within the access network. The functionality of such an EN isextended by the present invention as described herein. It is possiblefor any of the access networks to have any number of ENs, each locatedat any point in the network. Each of the functions performed by an EN isdescribed below:

1) Mobility Management: The mobility component of the network sub-layerprovides the framework to manage all mobility management-relatedfunctionality within an access network, as well as facilitating themobility of terminals across access networks. The entity enhancesexisting mobility management mechanisms by providing additionalinformation to make decisions regarding the movement of nodes bothwithin (intra) and across (inter) access networks. The framework alsoprovides a method for the mobility entity to interact with QoSparameters in the network through the QoS entity in the EN. The mobilitycomponent part of the EN plays the role of Mobility Agent in HMIPv6 (seeRFC 4140).

2) Quality of Service: The QoS component of the EN plays a vital role inproviding QoS both within and between heterogeneous networks. Thisentity provides a virtual link between access networks to shareinformation regarding resources and other QoS parameters. For example, aper-flow based QoS architecture such as IntServ can benefit with theadditional knowledge of the network in providing resource reservationsand reducing blocking probability. Re-establishing traffic flows afterhandover can also be enhanced by this entity, with the greater overviewknowledge of the network, traffic flows can be optimally redirected tothe new destination with minimum possible delays. This entity will workclosely with routing in the network in identifying the paths with therequired QoS. Traffic flow and congestion management also come underthis entity. The QoS entity can interact with other entities performingtasks such as traffic shaping, congestion control, traffic flowmanagement and QoS routing.

3) Signalling: The signalling entity of the EN plays an important part.This entity enables the EN to gather information and share informationthrough signalling other ENs. It is desirable to make use of a commonsignaling approach where possible to minimise the delay associated withsignalling sequentially. This allows the EN to process mobility and QoScombined signalling from the mobile nodes (MNs) or other entities thuspreventing sequential signalling which contribute to large delays. Thesignalling used here could utilise a common signalling approach such asthe QoS conditionalised handover binding update in X. Fu, H. Karl, andC. Kappler, “QoS-Conditionalized Handoff for Mobile IPv6,” inNetworking2002, ser. LNCS, vol. 2345, 2002, pp. 721-730.

In some embodiments of the invention (for example those in which theaccess network employs DiffSery or a similar protocol) the accessnetwork 16 also comprises a Bandwidth Broker (BB) 36. The BB 36 is alogical entity that is stored and executed on a network node within thedomain. Further details of the architecture and function of BandwidthBrokers can be found in “A Discussion of Bandwidth Broker Requirementsfor Internet Qbone Deployment”, Neilson, R. et al., August 1999 to whichreference is specifically made, hereinafter referred to as Neilson, thefull contents of which is incorporated herein for all purposes. Forexample the BB 36 may function on the gateway GW 32 in the accessnetwork 14, or it may reside on a physically separate network node. Thepurpose of the BB 36 is to manage the QoS resources within a domainbased on the Service Level Specifications (SLSs) that have been agreedin that domain (intra-domain communication), and to manage communicationwith other BBs in different domains (inter-domain communication). Inthis case, the BB 36 is responsible for the QoS resources in the accessnetwork 14. Given a specific QoS request by a mobility agent or otherBB, a BB determines whether or not the requested QoS can be met bynetwork nodes (usually routers) within the domain from one gateway inthe domain to another. Each BB has access to the routing table of thenetwork node on which it resides; accordingly by means of link stateadvertisement discussed in RFC 2676 it is aware of the QoS level (e.g.bandwidth) available over all links in its domain.

Referring to FIG. 2A one of the routers 24 comprises a housing 40, amemory 41, one or more CPU 42, switches 43 and physical interfaces 44.The physical interfaces 44 enable communication over a wired or wirelessphysical link with other routers 30 in the access network 14. The memory41 may store computer executable instructions that when executed bringabout the functionality one or more of the various logical entitiesdescribed herein, e.g. MR 20, MRHA 26, AR 30, GW 28, and EN 32, 34, 36.

Referring to FIG. 2B a VMN 22 on the moving network 18 comprises a case50 housing a CPU 52, an interface 54, a computer memory 56, a 3Gtransceiver (or interface) 58, a WLAN transceiver (or interface) 60 anda broadcast transceiver (or interface) 62. The 3G transceiver 58 and thebroadcast transceiver 62 are wired to an antenna 64 for reception andtransmission of data with a mobile network and/or the access point inthe moving network 18, and for reception of data from a broadcastnetwork respectively. The WLAN transceiver 60 enables reception andtransmission of data with wireless access points. The CPU 52 interfaceswith all of the aforementioned components to process (store, access,etc.) electronic data. The memory 56 stores computer executableinstructions that when executed by the CPU 44 perform the mobile nodemethod steps as described herein. These computer executable instructionsmay be stored in the memory of the mobile during manufacture. It is tobe noted that it is not essential for the mobile node to be multi-mode;the invention also has application for mobile nodes with only oneinterface, e.g. a WLAN or 3G transceiver.

Handover or Login Phase

When the moving network 18 wishes to attach to the access network 16(e.g. when the mobile router 20 moves it into the area of coverage of aNode B) it either awaits receipt of or solicits one or more RouterAdvertisement from an access router, in this case access router 30. TheRouter Advertisement comprises a MAP option that provides details ofeach target EN (distance vector from the mobile router, preference forthe particular EN, the EN's global IP address and subnet prefix). Theterm ‘target’ is used purely for convenience to distinguish between a‘serving’ EN (which may be located in the same or a different accessnetwork) with which the mobile router 20 is already registered, and a‘target’ EN that is a potential candidate for registration.

Assuming that several MAP options are received advertising differentENs, the mobile router 20 selects one of the ENs with which to registerusing the distance vector and/or preference value in the MAP option. Themobile router 20 then uses the network prefix in the MAP option toauto-configure both a regional and a local care-of address to registerwith the target EN 34. To do this the mobile router 20 follows theprocedure described in RFC 4140 to which reference is specifically madein this respect (see in particular section 6.1).

During normal operation all messages sent or received by MNs, be itcontrol-type messages or data, traverse the MR 20. Thus, the MR is ableto intercept QoS request messages (e.g. RSVP Path and Resv messages, andor network login type messages which comprise desired QoS parameters)from the mobile nodes attached to the MR 20, examine the trafficcharacteristics (e.g. represented by a flowspec or other QoS indicator)being requested by each, and record those requests in an internallymaintained database or otherwise, before forwarding them to execute thereservation procedure.

In particular, the MR intercepts any QoS-request messages and analysesthe details of the request by looking at the QoS related parameters,e.g. Tspec and RSpec, (which may include parameters such as requestedbandwidth, delay and jitter, for both the uplink and downlink). It willthen classify each QoS-request message into one of a set number oftraffic profiles based on the delay and other delay-relatedrequirements, for example into one of the four traffic classes of UMTS(i.e. conversational, streaming, interactive and background). Instead ofsimply forwarding each Resv and Path message onto the access network,the MR 20 uses the QoS database it has stored to determine a total QoSrequirement for each traffic profile; the combination of these total QoSrequirements is herein referred to as a ‘QoS aggregate’, that is thetotal QoS requirements of all nodes in the moving network 18. This QoSaggregate can be used to generate separate QoS-requests, e.g. an RSVPResv and Path messages, for the entire QoS requirements of the movingnetwork 18. These messages are addressed to the MRHA 26 and sent to theaccess network to which the moving network 18 is presently attached inorder to trigger reservation of resources up to the MRHA 26. If the QoSrequirements change (e.g. if new sessions are commenced and/or othersfinished) the MR 20 simply sends revised Resv and/or Path messages asper RFC 2205 section 2.3, or may send other QoS-request messages.

Once many sessions are underway, the moving network 18 appears to theaccess network 14 or 16 as a single mobile node that requires unusuallylarge resources e.g. in terms of reserved bandwidth. For example theremay be many tens or even hundreds of VMNs on a train and the mobilerouter 20 handles all of the sessions for the VMN s and any othersessions of LPNs and/or LMNs. Since all of the IP packet data (bothuplink and downlink) is tunnelled through the NEMOBT established betweenthe mobile router 20 and the MRHA 26, there is no possibility for IPpackets to take different routes through the access network to spreadthe load.

A further problem arises in that, for an access network operating atunnelling-type micro-mobility protocol such as HMIPv6, packet data isalso forced through a single mobility agent. In view of the potentiallyvery high resource requirements it is quite likely that no singlemobility agent in an access network will be able to meet the QoSrequirements of the whole moving network 18. As a result the mobilerouter 20 will have to blindly seek alternative mobility agents withwhich to make a resource reservation, or negotiate a lower resourcereservation with the intention of either dropping the sessions of someterminals, or proportionally reducing the QoS given to all sessions. Ineither case, handover latency will be increased.

In order to address this problem, when the moving network 18 performs ahandover (either inter or intra access network) the QoS aggregate of themoving network 18 (i.e. its entire QoS requirement) is split into two ormore smaller QoS aggregates, and each of those smaller QoS aggregates isregistered with a different mobility agent.

How the MR 20 proceeds at this stage of the handover is dependent onwhether or not the handover is an inter-access network handover or anintra-access network handover. To determine which is applicable, the MRexamines each MAP option that it receives and compares the advertisednetwork prefix against the or each RCoA that it has registered: any newnetwork prefixes indicate the possibility of an inter-access networkhandover, whereas if the advertised network prefix matches one or moreof the existing RCoAs an intra-access network handover is possible.

Inter-Access Network Handover

When the MR 20 enters the wireless coverage area of a new accessnetwork, and a handover is deemed necessary to the new network, the MR20 must transfer all ongoing sessions from the serving access network 14to the target access network 16, as shown in FIG. 1. In this embodiment,the handover is network-controlled and the target EN 34 performs most ofthe signalling. However, an alternative possibility is for the handoverto be controlled by the MR 20 and this is described in greater detailbelow in the second embodiment. Furthermore, it is assumed that themoving network 18 is moving from the access network 14 in FIG. 1, whichdoes not operate any tunnelling-type micro-mobility protocol, to theaccess network 16, which does.

Referring to FIG. 3, once the MR 20 has auto-configured the RCoA andLCoA as described above, it composes a combined mobility and QoSrequest. The purposes of this message is to enable the access network 16to perform mobility (e.g. register bindings) and QoS (e.g. takeadmission decisions) procedures in one step, before sending anyacknowledgement to the mobile router 20. By performing mobility and QoSprocedures together handover delay and packet loss is reduced. In thisembodiment the combined mobility and QoS request is a QoS-extendedbinding update (QBU) message. The QBU message is based on the localbinding update message described in RFC 4140 and a flag is used in thereserved part of the message to indicate to the target EN 34 that thelocal binding update is in fact a QBU message rather than a normal HMIPbinding update. Using the aforementioned QoS database, the MR 20 placesthe desired QoS parameters for each traffic profile in the Mobilityoptions part of the QBU message. The QoS parameters represent the entireQoS aggregate and may include characteristics of all of the trafficand/or each traffic class, including upper and lower bounds ofbandwidth, delay and jitter. To enable resources to be reserved bothupstream and downstream the QoS parameters may be included in the formof a Tspec (characterising traffic to be sent by the MR 20 into theaccess network 16) and a flow descriptor (comprising Rspec and filterspecification), characterising traffic to be received by the MR 20 fromthe access network 16; and whether or not the upstream and downstreamtraffic is to receive guaranteed QoS or controlled load.

At step S3-1 the MR 20 sends the QBU message to the target EN 34 usingthe global IP address advertised in the MAP option. At step S3-2 thetarget EN 34 firstly performs duplicate address detection (DAD) on theRCoA that the MR 20 has configured; if successful the target EN createsa binding for the MR 20 mapping the RCoA to the LCoA. The target EN 34then examines the QoS parameters contained in the QBU message anddetermines whether or not it can meet the requirements for each trafficprofile. To do this the target EN 34 performs an admission test in whichthe available bandwidth of the EN is determined and compared to thatrequested in the QBU message. If the target EN 34 is unable to meet therequested QoS requirements, it looks up alternative EN(s) in the accessnetwork 16 that might be able to meet some or all of the MR's QoSaggregate request. The table used for this lookup is stored in a memoryof the target EN 34; the table may be created and managed manually by anadministrator of the access network 16.

At step S3-3 the target EN 34 triggers reservation of the resources thatit can provide for the moving network 18; this is done in two ‘legs’: afirst leg from target EN to MR 20 (both upstream and downstream), and asecond leg from target EN to MRHA 26 (both upstream and downstream).Since RSVP over IntServ is receiver-initiated, the target EN 34 musttrigger the MR 20 to send RSVP Resv messages. Firstly the target EN 34generates the appropriate QoS parameters (e.g. a Tspec) characterisingthe traffic that it will send to the MR 20 i.e. in a downstreamdirection. These parameters are based on (1) the QoS parameters thetarget EN 34 received from the MR 20 (e.g. flow descriptor) and (2) theQoS parameters it has decided during the admission test that it is ableto provide. An RSVP Path message is then generated comprising these QoSparameters, and the message sent to the LCoA of the MR 20. The RSVP Pathmessage enables the routers between the target EN 34 and the MR 20 toroute the RSVP Resv messages along the correct downstream route back tothe target EN 34. Upon receiving the RSVP Path message, the MR 20 readsthe Tspec and responds with an RSVP Resv message comprising a flowdescriptor that matches the Tspec sent in the Path message by the targetEN 34. The Resv message causes resources to be reserved along thedownstream route from target EN 34 to MR 20.

To reserve the resources in the upstream direction between the MR 20 andtarget EN 34, the MR 20 now sends an RSVP Path message to the target EN34. The Tspec of this Path message is not important, as the target EN 34will simply respond with an RSVP Resv message comprising a flowdescriptor that it can support. On receipt of the Path message, thetarget EN 34 sends a Resv message to the MR 20, thereby reservingresources along the upstream route set by the Path message.

For the second leg, i.e. between the target EN 34 and MRHA 26, a similarprocess takes place except that the target EN 34 sends firstly an RSVPPath message with a Tspec characterising the upstream traffic it willsend to the MRHA 26. In response, the MRHA 26 sends a Resv message withQoS parameters matching the Tspec of the Path message. This triggers theMRHA 26 to send an RSVP Path message to the target EN 34 for downstreamtraffic; it is not important what the Tspec of this message is since thetarget EN 34 will only reserve the resources it can provide. Uponreceiving the Path message the target EN 34 sends a Resv message toreserve the resources along the downstream route established by the Pathmessages; the flow descriptor of the RSVP Resv messages match what thetarget EN 34 is able to provide for the MR 20.

If the access network 16 employs DiffServ, the process of resourcereservation is somewhat simpler. In particular, upon receiving the QBUmessage, the target EN 34 forwards the requested QoS parameters(contained in the Mobility options part of the message) to a bandwidthbroker (not shown in FIG. 1) which takes an admission decision. Thebandwidth broker either accepts or declines all or a part of the requestand sends the target EN 34 a suitable acknowledgement. If the bandwidthbroker cannot accept the whole QoS aggregate through the target EN 34,it examines its link state database to determine if any other EN in theaccess network could handle some or all of the remaining part of the QoSaggregate. If so, the bandwidth broker sends each identity of theappropriate EN to the target EN 34.

Once these resources have been reserved in the access network 16, thetarget EN 34 sends a QBU acknowledgement message to the MR 20 at stepS3-4. This message may be based on the Binding Acknowledgement describedin RFC 4140 for example. The QBU acknowledgement comprises datarepresenting:

(i) the RCoA assigned to the MR 20 (which may be different to the onecontained in the original QBU message, following DAD by the target EN34);

(ii) the amount of resources reserved for the MR 20 by the target EN 34(which might be expressed as a certain bandwidth, one or more permittedtraffic class, or a combination of both); and

(iii) resources available at alternative ENs with which the MR 20 mayestablish a QoS route.

Regarding (ii) the QBU acknowledgement may inform the MR 20 that onlycertain resources have been reserved; for example the target EN 34 mayhave reserved resources only for delay-sensitive traffic such as VoIPand streaming sessions. Regarding (iii) the QBU acknowledgement maysimply comprise a list of one or more alternative EN, or more detail maybe included, such as how much bandwidth is available at each alternativeEN and/or the traffic class(es) that it will accept within thatbandwidth.

Upon receipt of the QBU acknowledgement, the MR 20 reads the message andfirstly notices that its request for registration has been successful(at least in part). In response the MR 20 prepares and sends BindingUpdate (BU) to the MRHA 26 at step S3-5. Since the target EN 34 cannotmeet the entire QoS requirements of the MR 20, a flag is used from thereserved bits of the BU message to indicate that the BU is not a normalBU message. In particular, the flag causes the MRHA 26 to add the newRCoA (available from the source address of the BU) to its binding cache,but not delete the other RCoA in the binding cache. In this way two ormore NEMOBTs are created for the MR 20. In this example there are two:one NEMOBT passes across the access network 14 and the other passesacross the access network 16.

One alternative would be for the MR 20 to send all current RCoA(s),including the new RCoA being registered by the BU, in the MobilityOptions part of the BU. Upon receiving the BU, the MRHA 26 would comparethe list against its current binding cache and amend the cache to beconsistent. Accordingly the MRHA 26 may either remove one or morebinding entry, create one or more new binding entry, or do nothing. Inthis particular example, assuming that the MR 20 had only one RCoA priorto this inter-access network handover, the BU would comprise two RCoAs:one in the access network 14 and one in the new access network 16.

Another flag in the BU indicates to the MRHA 26 whether or not theMobility Options also carries a list of one or more traffic class. Uponreceiving a BU with this flag set, the MRHA 26 operates a trafficsplitting algorithm as follows. Depending on the circumstances, the MR20 may either leave the Mobility Options empty or may provide the list.In the first case it may be that the MR 20 has only one type of traffic(e.g. web browsing) at that point in time and therefore packets can besplit at random between the RCoAs i.e. randomly tunnelled either throughthe new or the old NEMOBT. In the second case the MR 20 uses theMobility Options part of the BU to inform the MRHA 26 which trafficclasses the target EN 34 has indicated that it will handle. For example,the target EN 34 may only be able to handle the conversational andstreaming traffic classes of the MR 20. In that case the MRHA 26 updatesits binding cache to associate the new RCoA with traffic of that type.Packets arriving at the MRHA 26 are examined by a packet classifier(which reads the TOS field for example). Packets are then sent eithervia one NEMO tunnel or the other according to their traffic type. Inanother example, the target EN 34 may have indicated that it will onlyhandle a maximum bandwidth for the MR 20, but is indifferent as to whichtype of traffic is passes through it. In that case, the MRHA 26 wouldsend only a certain bandwidth through the new NEMOBT via the target EN34, e.g. 5 MB s⁻¹ whilst the remainder e.g. 8 MB s⁻¹ would be sentthrough the old NEMOBT.

The traffic splitting algorithm is open to custom implementation by thenetwork operator. One possible mechanism would be to split trafficaccording to application type, such that delay sensitive traffic is sentacross the least congested path. The splitting algorithm may also takethe velocity of the moving network into account (the velocity may beobtained using GPS for example—the velocity of the moving network couldbe sent by the mobile router in a periodic signalling message), and sendthe highest priority traffic through the EN to which the connection ismost stable. The stability may be a function of the wireless signalstrength experienced by the MR and this signal strength may be reportedperiodically (e.g. every 10 s, 30 s or 60 s) to the MRHA. The MRHA maychoose the most stable network as that network from which the MR isexperiencing the best signal strength. This might be assessed on thebasis of the most recent signal strength reported, comparison with athreshold, or on the basis of a moving average for example.

A similar procedure happens at the MR 20 for upstream traffic. Inparticular, whichever traffic the target EN 34 has accepted in theupstream direction can be sent by the MR 20 via the new NEMOBT.Similarly, if the target EN 34 has indicated that it will handle onlycertain types of traffic or a maximum bandwidth, the MR 20 will actaccordingly by tunnelling packets with the appropriate RCoA, througheither the new or the old NEMOBT.

Accordingly at step S3-7 a portion of the packets begin to be tunnelledin both directions between the MRHA 26 and the MR 20 via the target EN34 using the new NEMOBT. The remainder of the packets follow the oldNEMOBT from the MRHA 26 to the MR 20.

The MR 20 now looks in the QBU acknowledgement for one or morealternative EN that might be able to provide some or all of itsremaining QoS requirements. Assuming that an IP address of analternative EN is found, the MR 20 sends a QBU message to thealternative EN and, as shown in FIG. 3 at step S3-8, the same steps(S3-1 to S3-7) are repeated with the alternative EN. In this second QBUmessage, the MR 20 requests the entire balance of its QoS aggregate tobe met by the alternative EN, although it is possible for the MR 20 torequest some fraction of the outstanding balance.

Upon receipt of the second QBU acknowledgement, the MR 20 either has allof the remaining part of the QoS aggregate met by the alternative EN, orthere may still be some QoS requirement outstanding. The second QBUacknowledgement may suggest some other EN that might be able to meet theremaining requirement. It is possible that this other EN may be thetarget EN 34 (for example if there were only two ENs in the accessnetwork 16). To avoid the MR 20 being ‘bounced’ between ENs, the MR 20stores a record of the or each EN that it has already sent a QBU messageto in the current handover. During that handover, no further QBU messageshould be sent to any of these ENs. The process of sending QBU messagesto new alternative ENs can be repeated until all options are exhausted,or may be stopped after a pre-determined number of attempts, e.g. three.

Once the MR 20 sends a BU to the MRHA 26, there are now two or moreNEMOBTs through the access network 16 which together serve some or allof the QoS aggregate of the MR 20. In any event, the network should beable to support a greater proportion of the QoS aggregate than a singlemobility agent would otherwise. If the entire QoS aggregate has been metby one or more EN in the access network 16, the binding in the MRHA 26for the MR 20 to the previous access network 14 will eventually expireleaving only the bindings to RCoA(s) in the new access network 16.Alternatively, once handover at the physical and link layers has beencompleted, the MR 20 may cause this ‘old’ NEMOBT to be torn down bysending a final BU that lists only one or more EN in the access network16.

When the MR 20 moves but stays within the EN domain with which it isregistered, no global change in its RCoA is necessary, as per HMIP.Instead the MR 20 sends a local binding update to the EN 34 which bindsthe new LCoA to the existing RCoA. If the access network uses DiffServ,no QoS reservation needs to take place since the MR 20 already has areservation with the bandwidth broker. If the access network employsIntServ resources will need to be reserved between the EN 34 and the newaccess router. This is achieved as per the second leg of resourcereservation as described above.

Intra-Access Network Handover

Whilst the MR 20 is attached to the access network 16, and since theaccess network utilizes a micro-mobility tunnelling protocol, the MR 20may at any time handover from one access router to another withoutchanging any of its RCoAs. However, if the MR's QoS requirements changeor if the MR 20 moves to the edge of the domain of one of its ENs, itmay be necessary for the MR 20 to perform an intra-access network ENhandover. FIG. 4 shows an example scenario where the MR 20 wishes tohandover from EN₁ to EN₃, whilst maintaining its registration with EN₂.

The MR 20 sends a QBU message to EN₃ using the MAP option it hasreceived in a router advertisement, sent by AR₄ for example. Uponreceipt EN₃ initiates steps S3-1 to S3-7 in order to reserve resourcesfor the some or all of the QoS aggregate of the MR 20. EN₃ sends a QBUacknowledgement to the MR 20 informing it what resources have beenreserved. Assuming that EN₃ can meet the same level of QoS that EN₁provided, the MR 20 may simply send a BU to the MRHA 26 comprising theRCoA it has at the EN₂ and EN₃. The absence of the RCoA of the MR at EN₁acts as a trigger for the MRHA 26 to remove that RCoA from its bindingcache. The resources that were reserved for the MR 20 through EN₁ willeventually expire in the absence of the required periodic RSVP Resvmessages.

Fallback Mechanism

In the event that only one EN is available in an access network, orwhere the QoS aggregate cannot be met by a combination of ENs, the MR 20should establish other QoS-enabled paths directly with the MRHA 26 usingthe NEMO Basic Support protocol (see RFC 3963). In this way the MR 20can bypass the EN(s) and use less congested paths. However, the penaltyis that BUs to the MRHA 26 become more frequent as one BU is requiredfor each handover between access routers. Therefore, use of such pathsshould preferably be reserved for delay-tolerant applications such ase-mail and file transfer. To prevent these normal binding updates fromreplacing the entire binding cache for the MR 20 at the MRHA 26 with oneRCoA (since other paths through one or more EN may still be in use), theMR 20 uses the modified BU described above in which a flag is set toindicate that the MRHA 26 should act as above.

EN Resource Information Exchange

Each EN should as far as practical contain up to date information aboutneighboring ENs, to allow it to suggest alternative ENs to the MR 20when it cannot meet the QoS aggregate requirements of the moving network18. To facilitate in the exchange of such information, one possibilityis for a Bandwidth Broker (BB) to be located in each access networkwhich acts as a common point for all ENs in the access network to updatetheir resource availability. ENs must ensure that the BB is kept up todate about their resource availability. The BB will then, eitherperiodically or otherwise, broadcast EN resource information to all ENswithin the AN, to allow each to make decisions about alternative ENs.Existing protocols such as the simple network management protocol (SNMP)(see RFC 3411) can be used to facilitate the exchange of suchinformation between the BB and ENs. A BB could be used with an accessnetwork employing either DiffSery or IntServ for example. An alternativeis for the access network to operate an intra-domain link state routingalgorithm such as QoSPF, whereby each router in the access networkbuilds and stores a routing table with the link cost to every otherdestination within the administrative domain of the network. In thisway, each EN will be able to make an admission decision by using such arouting table when a QBU message is received from a MR.

An alternative to the aforementioned network-controlled handover methodis a mobile router-controlled method, which removes the restriction touse a QoS protocol supporting reservation procedures, such as IntServwith RSVP. The mobile router-controlled method is similar to thenetwork-controlled method, except that QoS reservations are triggered bythe MR instead of the EN.

An example of the MR-controlled method is shown in FIG. 5. At step S5-1the MR 20 sends a QoS request in the form of a QBU message to the targetEN 34. Upon receiving the QBU message, the target EN 34 checks itsavailable resources and looks up one or more alternative EN that mightalso be able to provide resources. At step S5-2 the target EN respondswith a QBU acknowledgement message; this is similar to that describedabove, except that a flag is set to indicate to the MR 20 that noresources have been reserved yet. The QBU acknowledgement indicates theresources the target EN 34 can accommodate, as well as information aboutalternative EN(s) that might be able to meet its remaining resourcerequirements. The MR 20 triggers resource reservation by sending an RSVPPath message to the target EN 34, establishing a route for upstreamtraffic from the MR 20. Upon receipt the target EN 34 then sends an RSVPResv message to the MR 20 (reserving resources in the upstream directionalong the route), and sends an RSVP Path message to the MR 20 toestablish the route for downstream traffic with a Tspec matching the QoSparameters it will provide. The MR 20 responds by sending an RSVP Resvmessage to reserve resources for traffic in the downstream directionalong the route. In order to reserve resources between the target EN 34and MRHA 26 in both directions, a similar process takes place. This isstarted by the target EN 34 upon receipt of the RSVP Path message fromthe MR 20. Once all reservation acknowledgements have been received, theMR 20 sends a binding update to the MRHA 26 at step S5-4 in the same wayas that described in the first embodiment. The remaining bindings andreservations carried out with the alternative suggested ENs follow thesame procedure as with the target EN 34; only the first phase is shownin FIG. 4, as the subsequent phases are very similar to the first.

Embodiments of the invention enable a moving network utilizing a mobilerouter to perform a handover within (intra) and between (inter)micro-mobility-enabled access networks, and to take advantage ofmicro-mobility, but at the same time ensuring that:

(i) the QoS of a number, and preferably most sessions is preserved: inparticular, under a micro-mobility protocol such as HMIPv6, packets mustflow through the bottleneck presented by the mobility agent beforereaching the mobile router. With the potentially large number ofsessions of a moving network, there is a possibility that no singlemobility agent would have the capacity for all flows served by themobile router, requiring some sessions to be dropped, or the QoS of allsessions proportionally reduced. At least some embodiments of thepresent invention reduce the need to take such action by providing themobile router with knowledge of alternative mobility agents, enablingset up of multiple mobility agent registrations, and distribution of thetraffic amongst those mobility agents.

(ii) there is little or no perceivable interruption (from the end-user'sperspective) in communications: currently, mobile routers must firstestablish a binding with a EN, and then carry out resource reservationprocedures. If a reservation is rejected by the EN due to insufficientresources, the EN must take further courses of action, albeit in asomewhat blind fashion, until all or most sessions have been connectedthrough the new access network. The time taken to carry out suchprocedures may cause a perceivable interruption in communications tousers. At least some embodiments of the present invention attempt toreduce any perceived interruption in communication by:

(a) combining QoS operation with mobility management operation;

(b) allowing available capacity at the EN with which the firstregistration is attempted by the MR to be granted to a portion of thesessions in the interim, until the aggregate QoS requirements of themoving network have been satisfied.

In embodiments of the invention in which an access network employsDiffSery over an intra-domain link state routing algorithm the entitiestransmitting packets (MR, EN and MRHA) may use source routing that iseither strict or loose. At one extreme the MR and MRHA may use loosesource routing that only requires packets to pass through a certain EN;the remaining routers can be determined on a hop-by-hop basis. Each ENmay also use loose source routing for any packets that it sends eitherdownstream to the MR or upstream to the MRHA. At another extreme the EN,MR and MRHA may use strict source routing to specify the complete pathto the destination.

The term handover as used herein includes inter-MAP domain handoverwithin one access network i.e. where mobility agents are located in thesame administrative domain, and inter-access network handover from oneaccess network to another i.e. where mobility agents are located indifferent administrative domains.

The MNs 22 may be a hand-held mobile terminals such as a cellular/mobilephones, PDAs, digital media players or notebook computers for example.

It will be appreciated that the invention is applicable to all varietiesof micro mobility protocols and QoS routing protocols.

Examples of moving networks include, but are not limited to:

(a) networks attached to people (“Personal Area Networks” or PANs): amobile phone with one cellular interface and one Bluetooth interfacetogether with a Bluetooth-enabled PDA. The mobile phone is the MR whilethe PDA is used for web browsing or runs a personal web server;

(b) networks of sensors and computers deployed in vehicles: vehicles areprovided with an increasing number of processing units for safety andease of driving, as well as Internet access for passengers;

(c) access networks deployed in public transportation (buses, trains,taxis, aircraft, etc.): they provide Internet access to IP devicescarried by passengers (e.g. laptop, camera, mobile phone representinghost mobility within network mobility, or PANs i.e. network mobilitywithin network mobility or “nested mobility”); and

(d) ad-hoc networks connected to the Internet via a MR: for examplestudents in a train that need to set up an ad-hoc network amongstthemselves and then enable the ad-hoc network with Internet accessthrough the MR.

Mobile routers may be installed in a wide range of vehicles includingprivate vehicles (e.g. cars, motorbikes), public transport and militaryvehicles (aircraft, tanks, lorries, boats, etc.)

Although the embodiments of the invention described with reference tothe drawings comprises computer apparatus and methods performed incomputer apparatus, the invention also extends to computer programs,particularly computer programs on or in a carrier, adapted for puttingthe invention into practice. The program may be in the form of sourcecode, object code, a code intermediate source and object code such as inpartially compiled form, or in any other form suitable for use in theimplementation of the methods according to the invention. The carriermay be any entity or device capable of carrying the program. Forexample, the carrier may comprise a storage medium, such as a ROM, forexample a CD ROM or a semiconductor ROM, or a magnetic recording medium,for example a floppy disc or hard disk. Further, the carrier may be atransmissible carrier such as an electrical or optical signal that maybe conveyed via electrical or optical cable or by radio or other means.

When the program is embodied in a signal that may be conveyed directlyby a cable or other device or means, the carrier may be constituted bysuch cable or other device or means. Alternatively, the carrier may bean integrated circuit in which the program is embedded, the integratedcircuit being adapted for performing, or for use in the performance of,the relevant methods.

1. In a wireless network environment comprising a mobile router servinga moving network, said mobile router for attaching to a packet-switchedaccess network that uses a micro-mobility protocol and a Quality ofService (QoS) protocol to route packet data to and from said mobilerouter, wherein said mobile router has a QoS aggregate requirementgenerated by nodes attached thereto, a method of handover of said mobilerouter to a mobility agent in said access network, which methodcomprises the steps of: (i) said mobile router sends a QoS requestmessage to said mobility agent, which QoS request message comprises aQoS parameter representing said QoS aggregate; (ii) upon receipt by saidmobility agent, said access network takes a QoS admission decision onthe basis of said QoS parameter; and (iii) said mobility agent sends aQoS acknowledgement to said mobile router whereby said mobility agentinforms said mobile router of the outcome of said QoS admissiondecision; characterized by the step of (iv) if said QoS admissiondecision is that said mobility agent cannot handle all of said QoSaggregate, said QoS acknowledgement comprises an identity of one or morealternative mobility agent that might meet at least a part of said QoSaggregate that will not be provided by said mobility agent.
 2. A methodaccording to claim 1, wherein said QoS request comprises a BindingUpdate message in which said QoS parameter representing said QoSaggregate is sent within a Mobility Options part of said Binding Updatemessage, whereby upon receipt of said Binding Update said mobility agentis informed both about a care-of address that said mobile router intendsto use and a desired QoS.
 3. A method according to claim 1, wherein saidQoS admission decision comprises determining a proportion of said QoSaggregate that said mobility agent can provide, and sending datarepresenting said proportion in said QoS acknowledgement to said mobilerouter. Proportion could be in terms of traffic class or in terms ofbandwidth.
 4. A method according to claim 1, wherein said QoSacknowledgement comprises a Binding Acknowledgement type message andsaid identity of said one or more alternative mobility agent is sentwithin a Mobility options part of said Binding Update.
 5. A methodaccording to claim 1, wherein said QoS acknowledgement further comprisesan indication of resources available at said one or more other mobilityagent.
 6. A method according to claim 4, wherein data representing QoSthat will be provided by said mobility agent for said mobile router issent in a Mobility Options part of said Binding Acknowledgement, wherebyupon receipt of said Binding Acknowledgement said mobile router isinformed both about a care-of address that has been registered by saidmobility agent for said mobile router and about the QoS that saidmobility agent is able provide.
 7. A method according to claim 3,wherein upon receipt of said QoS acknowledgement said mobile routersends a further QoS request to one of said one or more alternativemobility agent, which further QoS request seeks reservation of theremainder of said QoS aggregate that has not been admitted by saidaccess network through said mobility agent.
 8. A method according toclaim 7, further comprising the steps of said mobile router sending QoSrequests to different mobility agents, until said QoS aggregate issupported by said access network via a number of different mobilityagents, until no untried mobility agents are left in said accessnetwork, or until a predetermined number of QoS requests have been sentby said mobile router.
 9. A method according to claim 1, furthercomprising the steps of said mobile router registering with at least twomobility agents, and sending at least one Binding Update to a mobilerouter home agent whereby each care-of address (RCoA) of said mobilerouter at each mobility agent is stored in a binding cache of saidmobile router home agent, so that traffic passing between said mobilerouter home agent and said mobile router is split between at least twotunnels, each tunnel passing through a different mobility agent, wherebysaid access network is able to support a greater proportion of said QoSaggregate than would otherwise be supported by a single mobility agent.10. A method according to claim 9, wherein said Binding Update comprisesa list of the or each care-of address belonging to the mobile router,the method further comprising the step of upon receipt of said BindingUpdate said mobile router home agent amending its binding cache to matchsaid list.
 11. A method according to claim 10, wherein said BindingUpdate further comprises a QoS parameter which is mapped to a respectivecare-of address in said list, the method further comprising the step ofsaid mobile router home agent splitting downstream traffic between saidcare-of addresses according to said QoS parameters.
 12. A methodaccording to claim 9, further comprising the steps of sending relativelydelay intolerant traffic through one of said at least two tunnels, andsending relatively delay tolerant traffic through another of said atleast two tunnels.
 13. A method according to claim 9, further comprisingthe step of sending one or more class of traffic through one of said atleast two tunnels, and sending at least one other class of trafficthrough another of said at least two tunnels.
 14. A method according toclaim 1, wherein step (i) follows completion of a mobility part of saidhandover.
 15. A method according to claim 1, wherein said QoS requestcomprises a combined mobility and QoS request, whereby upon receipt ofsaid combined request said mobility agent registers said mobile routerin a binding cache for the purposes of mobility, and said access networktakes said QoS admission decision for said QoS aggregate of said mobilerouter, before sending a combined mobility and QoS acknowledgement tosaid mobile router.
 16. A packet-switched wireless access networkcomprising a mobile router serving a moving network, said mobile routerfor attaching to a packet-switched access network that uses amicro-mobility protocol and a Quality of Service (QoS) protocol to routepacket data to and from said mobile router, wherein said mobile routerhas a QoS aggregate requirement generated by nodes attached thereto,said mobility agent configured to: (i) receive a QoS request messagefrom said mobile router which QoS request message comprises a QoSparameter representing said QoS aggregate; (ii) upon receipt of said QoSrequest message to cause said access network to take a QoS admissiondecision on the basis of said QoS parameter; (iii) send a QoSacknowledgement to said mobile router whereby said mobility agentinforms said mobile router of the outcome of said QoS admissiondecision; and (iv) if said QoS admission decision is that said mobilityagent cannot handle all of said QoS aggregate, said QoS acknowledgementcomprises an identity of one or more alternative mobility agent thatmight meet at least a part of said QoS aggregate that will not beprovided by said mobility agent.
 17. A router for use in a wirelessnetwork environment comprising a mobile router serving a moving network,said mobile router for attaching to a packet-switched access networkthat uses a micro-mobility protocol and a Quality of Service (QoS)protocol to route packet data to and from said mobile router, whereinsaid mobile router has a QoS aggregate requirement generated by nodesattached thereto, which router comprises a memory storing computerexecutable instructions that when executed perform the steps of: (i)receiving a QoS request message from said mobile router which QoSrequest message comprises a QoS parameter representing said QoSaggregate; (ii) upon receipt of said QoS request message to cause saidaccess network to take a QoS admission decision on the basis of said QoSparameter; (iii) send a QoS acknowledgement to said mobile routerwhereby said mobility agent informs said mobile router of the outcome ofsaid QoS admission decision; and (iv) if said QoS admission decision isthat said mobility agent cannot handle all of said QoS aggregate, saidQoS acknowledgement comprises an identity of one or more alternativemobility agent that might meet at least a part of said QoS aggregatethat will not be provided by said mobility agent.
 18. A mobile routerfor use in a wireless network environment comprising a mobile routerserving a moving network, said mobile router for attaching to apacket-switched access network that uses a micro-mobility protocol and aQuality of Service (QoS) protocol to route packet data to and from saidmobile router, wherein said mobile router has a QoS aggregaterequirement generated by nodes attached thereto, which mobile routercomprises a memory storing computer executable instructions that whenexecuted perform the step of sending a QoS request message to saidmobility agent, which QoS request message comprises a QoS parameterrepresenting said QoS aggregate.
 19. A vehicle comprising a mobilerouter having a memory storing computer executable instructions thatwhen executed perform the step of sending a QoS request message to amobility agent, which QoS request message comprises a QoS parameterrepresenting said QoS aggregate.